This chapter looks at the configuration and setup required to use either SLIP (Serial
Line Internet Protocol) or PPP (Point to Point Protocol) on your Linux system. This
follows the general TCP/IP configuration performed in the previous chapter. Both SLIP and
PP work over a dialup modem, essentially establishing a normal modem link with a remote
system, then invoking either the SLIP or PPP protocols. In many ways, SLIP and PPP are
like PLIP interfaces; even though SLIP and PPP use a serial modem port, they are really
point-to-point interfaces involving two machines. Unfortunately, SLIP and PPP are more
complicated to configure than PLIP.
You can do the SLIP and PPP configuration when you are configuring the general TCP/IP
files, or you can wait until you need to set them up for SLIP or PPP access. Since not all
installations will require SLIP or PPP, you can quite easily wait. However, most Internet
service providers prefer SLIP or PPP access from small systems, because they provide fast,
efficient transfers.
What's a dummy interface? It's a bit of a trick to give your machine an IP address to
work with when it uses only SLIP and PPP interfaces. A dummy interface solves the problem
of a stand-alone machine (no network cards connecting it to other machines) whose only
valid IP address to which data can be sent is the loopback driver (127.0.0.1). While SLIP
and PPP may be used for connecting your machine to the outside world, when the interface
is not active you have no internal IP address that applications can use.
The problem arises with some applications that require a valid IP address to work. Some
word processors and desktop layout tools, for example, require the TCP/IP system to be
operational with an IP address for the target machine. The dummy interface essentially
sets an IP address for your local machine that is valid as far as TCP/IP is concerned, but
doesn't really get used except to fool applications.
Creating a dummy interface using the loopback driver is very simple. If your machine
has an IP address already assigned for it in the /etc/hosts file, all you need to do is
set up the interface and create a route. The following two commands are required:
ifconfig lo 127.0.0.1 route add 127.0.0.1
The lo portion of the ifconfig command indicates that the line refers to the loopback
driver. This line creates a link to the IP address 127.0.0.1. If you do not have an IP
address for the localhost already in the /etc/hosts file, add one before you create the
dummy interface. To create the loopback interface, edit the /etc/hosts file so it includes
a line like the following:
127.0.0.1 localhost
This line sets up your local machine to use the IP address 127.0.0.1 as the localhost
interface. You can verify that the loopback interface is working properly after you have
used the ifconfig command by using the ifconfig command with the interface name to show
statistics:
merlin $ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:2000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 TX packets:12 errors:0 dropped:0 overruns:0
The statistics show that the loopback interface is running, has been assigned the IP address 127.0.0.1, and has the broadcast mask of 255.0.0.0.
After you add the loopback driver to the routing table using the route command, you can
use the ping command to check that the interface is responding properly:
merlin $ ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.7 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.7 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.7 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=0.7 ms
--- localhost ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.7/0.7/0.8 ms
You must interrupt the ping command with a Ctrl+C to stop it. The output above shows
that the packets destined for the localhost machine were properly delivered and replies
were almost immediate. If you receive output anything like this output, your interface is
properly set up. If you receive an unknown host message, your localhost name is not
recognized. Check the /etc/hosts file and use ifconfig to verify that the loopback driver
is installed properly.
SLIP can be used with many dial-up Internet service providers, as well as for
networking with other machines. When a modem connection is established, you don't get to
see a shell prompt, but SLIP takes over and maintains the session for you. The SLIP driver
is usually configured as part of the Linux kernel. The Linux SLIP driver also handles
CSLIP, a compressed SLIP version that is available with some implementations.
For most Linux systems that use SLIP, a serial port has to be dedicated to the device.
This means that a serial port must be specifically configured to use SLIP and cannot be
used for any other purpose. The kernel uses a special program called SLIPDISC (SLIP
discipline) to control the serial port, and blocks other non-SLIP applications from using
it.
The Linux SLIP driver is installed into the kernel usually by default, but some
versions of Linux require you to rebuild the kernel and answer y to a question about SLIP
and CSLIP usage. Once you have the kernel SLIP drivers in place, you can configure the
serial port to be used for SLIP.
The easiest way to dedicate a serial port for SLIP is to use the slattach program. This
takes the device name of the serial port as an argument. For example, to dedicate the
second serial port (/dev/cua1) to SLIP, you would issue the command:
slattach /dev/cua1 &
The command is set into background mode by the ampersand. Failure to send to background
means the terminal or console the command was issued from is not usable until the process
is terminated. You can embed the slattach command in a startup file if you want.
Once the attachment has succeeded, the port is set to the first SLIP device /dev/sl0.
If you are using more than one serial port for SLIP lines, you need to issue the command
for each line. Subsequent SLIP devices (/dev/sl1, /dev/sl2, and so on) will be assigned by
slattach. Most versions of Linux will support up to eight SLIP lines.
By default, most Linux systems set the SLIP port to use CSLIP. If you want to override
this default, use the -p option and the slip name:
slattach -p slip /dev/cua1 &
You can use modes other than slip and cslip to follow the -p option: slip6 (a six-bit
version of SLIP) and adaptive (for adaptive SLIP, which adjusts to whatever is at the
other end of the connection).
You must make sure that both ends of the connection use the same form of SLIP. For
example, you cannot set your device for CSLIP and communicate with another machine running
SLIP. If the versions of SLIP don't match, commands such as ping will fail.
Once the serial port has been set for SLIP usage, you can configure the network
interface using the same procedure used for normal network connections (including the
dummy interface set up earlier). The commands used are ifconfig and route. For example, if
your machine is called merlin and you are calling arthur, issue the commands:
ifconfig sl0 merlin-slip pointopoint arthur
route add arthur
The ifconfig command above configures the interface merlin-slip (the local address of
the SLIP interface) to be a point-to-point connection to arthur. The route command adds
the remote machine called arthur to the routing tables. You can also issue another route
command to set the default route to arthur as a gateway:
route add default gw arthur
If you want to use the SLIP port for access to the Internet, it has to have an IP
address and an entry in the /etc/hosts file. That gives the SLIP system a valid entry on
the Internet. A better approach is to use DNS, but the configuration is more complex (see
"Using DNS for SLIP and PPP," below).
Once the ifconfig and route commands have been executed, you can test and use your SLIP
network. If you decide to remove the SLIP interface in the future, you must remove the
routing entry, use ifconfig to take down the SLIP interface, and then kill the slattach
process. The first two steps are done with these commands:
route del arthur
ifconfig sl0 down
while the termination of the slattach process must be done by finding the process ID
(PID) of slattach (with the ps command), and then issuing a kill command. See Chapter 20, "Processes," for more information on the ps and
kill commands.
Many Linux versions include a utility program called dip (Dial-up IP), which helps to
automate the preceding steps, as well as provide an interpretive language for the SLIP
line. Many versions of dip are currently available, some of which have different
capabilities. This section doesn't go into exhaustive detail about dip, primarily because
most of its functionality is not used by most users. This section looks at a typical setup
file and leaves the rest to the documentation supplied with dip.
The dip system uses scripts to control its behavior. The following is a sample dip
script to connect to a remote machine with comments (prefaced by a pound sign) to explain
each action:
# dip script to connect to remote darkstar # begin by setting local interface name and address get $local merlin-slip # now set the remote end name and address get $remote darkstar # now set parameters port cua1 # serial port /dev/cua1 used for SLIP speed 38400 # use 38,400 as the modem speed modem HAYES # set the command set type for the modem # initialize modem reset # reset the modem and port flush # remove any modem responses # dial darkstar and log in dial 5551234 # dial the remote wait CONNECT # wait for the CONNECT message send \r\n\r\n # send a couple of CR/LFs wait ogin: # wait for login prompt send $merlin\n wait word: # wait for password prompt send secret1\n print Connected to the remote # now clean up default # set this link to default mode SLIP # go to SLIP mode
The script would be called and executed with a command like this
dip script_file
where script_file is the name of the file containing the script. You can put lots of
extra steps in the script, including multiple levels of error checking, however, since
most people find SLIP fairly easy to work with anyway, the dip utility is really for the
person who wants to perform extra automated steps.
PPP is a more talented protocol than SLIP and is preferable for most uses. However, the
configuration is a little more complex than SLIP's. Linux divides the PPP functions into
two parts, one for the High-Level Data Link Control (HLDC) protocol, which helps define
the rules for sending PPP datagrams between the two machines; and one for the PPP daemon,
called pppd, which handles the protocol once the HLDC system has established
communications parameters. In addition, Linux uses a program called chat, which calls the
remote system.
As with SLIP, PPP establishes a modem link between the two machines, and then hands
over the control of the line to PPP. You, as the user, never get to see a shell prompt or
login, because PPP handles it all for you. Both HLDC and pppd are complex utilities with
many options available to fine-tune their behavior. Since most of these options will never
be used by you, we can safely ignore all but the most important aspects necessary to get a
PPP connection up and running properly.
Prior to establishing a PPP link, you must have a loopback driver established (see Chapter 30, "Configuring TCP/IP"). You should also have a
name resolution system in operation, even if it's the /etc/hosts file or a simple DNS
cache-only name server (see "Using DNS for SLIP and PPP," below).
If you are worried about compromising your system's security, it is best to use PPP
with a special user account (for example, one called ppp) for optimum protection and
behavior. If you use a standard user login, there is a chance that people calling your
system can exploit file permission weaknesses to access parts of the system you don't want
them to touch. The use of a dedicated login for PPP is not strictly necessary, and you can
easily use PPP from any user account, but for more secure operation, you should consider
creating a ppp user. The process is simple. First, you need to add a new user to the
/etc/passwd file. You can use whatever script your system normally uses to add new users,
or edit the /etc/passwd file yourself. (See Chapter 16,
"Users and Logins," for more information about users and /etc/passwd.)
A sample /etc/passwd entry for the ppp account (with UID set to 201 and GID set to 51)
looks like this:
ppp:*:201:51:PPP account:/tmp:/etc/ppp/pppscript
In this case, the account is set with no password (so no one can log in to the account)
and a home directory of /tmp (since no files are created). The startup program is set to
/etc/ppp/pppscript, a file you create with the configuration information in it (you can
use any filename, of course). A sample contents for the pppscript file looks like this:
#!/bin/sh mesg n stty -echo exec pppd -detach silent modem crtscts
The first line forces execution of the script into the Bourne shell. The second command
turns off all attempts to write to the ppp account's tty. The stty command is necessary to
stop everything the remote sends from being echoed again. Finally, the exec command runs
the pppd daemon (which handles all PPP traffic). You will see the pppd daemon and the
options later in this section.
PPP requires you to establish a modem connection to the remote machine before it can
take over and handle the communications. The chat program is the most commonly used of the
utilities available to do this. The chat program is popular because it uses a scripting
style similar to that used by UUCP (see Chapter 27,
"UUCP").
To use chat, you have to assemble a command line that looks almost the same as a UUCP
/etc/Systems file entry. For example, to call a remote machine with a Hayes-compatible
modem (using the AT command set) at the number 555-1234, use the following command. It is
all formatted as a chat script, UUCP style:
chat "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1
If you read the UUCP chapter, this code may look familiar. If not, all the entries are
in a send-expect format, with what you send to the remote specified after what you receive
from it. The chat script always starts with an expect string, which you must set to be
empty because the modem won't talk to us without any signal to it. After the empty string,
send the ATZ (reset) command, wait for an OK back from the modem, and then send the dial
command. Once a CONNECT message is received back from the modem, the login script for the
remote machine is executed. Send a blank character, wait for the ogin: (login) prompt,
send the login name ppp, wait for word: (password) prompt, and then send your password.
After the login is complete, chat terminates but leaves the line open.
If you want to see all the activity that goes on with the chat program, you can force
all messages to the syslog daemon for future study. The -v option forces the messages to
syslog, so the command would be:
chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin:
ppp word: secret1
If the other end of the connection doesn't answer with a login script as soon as its
modem answers, you may have to force a Break command down the line to jog the remote end.
This is done the same way as with UUCP:
chat -v "" ATZ OK ATDT5551234 CONNECT ""
ogin:-BREAK-ogin: ppp word: secret1
Because any user doing a ps -ef command sees the entire command line (with its
passwords), this type of chat entry has a security problem. If you are the only user of
your system, this isn't a concern, but to save yourself any problems, you can embed the
script portion of the command in a file and read the file in to chat. Then the script will
not appear on a ps output. To call a file for use with chat, use the -f option:
chat -f chat_file
The chat_file will contain the string:
"" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word:
secret1
The chat script can help you detect common error conditions, such as a line busy or no
connection established. The messages from your modem (Hayes uses BUSY and NO CARRIER
respectively) are embedded in the chat script with the ABORT option, which enables you to
exit from the chat script gracefully if one of these error conditions occurs.
To handle these abort conditions, embed the chat keyword ABORT, followed by the message
that should trigger an abort, prior to your normal chat script. For example, to modify the
chat script above to abort on a BUSY or NO CARRIER message from the modem, the script
should look like this:
ABORT BUSY ABORT 'NO CARRIER' "" ATZ OK ATDT5551234
CONNECT "" ogin: ppp word: secret1
You need two ABORT commands because each takes only one argument. The rest of the chat
script is as usual. Note the need to put quotation marks around the NO CARRIER message:
the space in the middle would confuse the script otherwise.
To set up a PPP connection, you need to invoke the pppd daemon. If you have a PPP
connection already established and your machine is logged into a remote using the ppp
account, you can start the pppd daemon. If we assume your local machine is using the
device /dev/cua1 for its PPP connection at 38,400 baud, you would start up the pppd daemon
with this command:
pppd /dev/cua1 38400 crtscts defaultroute
This command tells the Linux kernel to switch the interface on /dev/cua1 to PPP, and to
establish an IP link to the remote machine. The crtscts option, which is usually used on
any PPP connection about 9,600 baud, switches on hardware handshaking. The IP address the
local system will use is taken from the local hostname, unless one is specified on the
pppd command line (which you will seldom need to do, since the localhost IP address should
be correct for the PPP line).
If you want to force the local or remote IP addresses to be something other than the
machine's default values, you can add the addresses with an option to pppd. The general
format is to specify the local IP address, a colon, and then the remote IP address. For
example, the option
147.23.43.1:36.23.1.34
when added to the pppd command line, sets the local IP address as 147.23.43.1 and the remote IP address to 36.23.1.34, regardless of that the local values are. If you only want to modify one IP address, leave the other portion blank. The command
147.23.43.1:
just sets the local IP address and accepts the remote IP address as whatever the
machine sends.
Because you need chat to establish the connection in the first place, you can embed the
chat command as part of the pppd command if you want. This is best done when reading the
contents of the chat script from a file (using the -f option). For example, you could
issue the pppd command:
pppd connect "chat -f chat_file" /dev/cua1 38400 -detach
crtscts modem defaultroute
You will notice a few modifications to the pppd command other than the addition of the
chat command in quotation marks. The connect command specifies the dialup script that pppd
should start with, while the -detach command tells pppd not to detach from the console and
not to move to the background. The modem keyword tells pppd to monitor the modem port (in
case the line drops prematurely) and hang up the line when the call is finished.
The pppd daemon begins setting up the connection parameters with the remote by
exchanging IP addresses, and then sets communications values based on transferred
information. Once that is done, pppd will set the network layer on your Linux kernel to
use the PPP link by setting the interface to /dev/ppp0 (if it's the first PPP link active
on the machine). Finally, pppd establishes a kernel routing table entry to point to the
machine on the other end of the PPP link.
If you want to change the default behavior of the pppd daemon, you can do it through
command line options or a control file. The file is a better approach if you want to
change the parameters for every connection established using PPP.
Before completing the command line, pppd scans a number of possible options files. The
more common file is /etc/ppp/options, which usually is used to set global defaults. An
example of a /etc/ppp/options file looks like this:
# /etc/ppp/options: globabl definitions domain merlin.com auth # force authentication usehostname # use local hostname for authentication lock # use file locking UUCP-style
The domain is established with the domain keyname followed by the full domain name
(minus the machine name). The next two lines above (auth and usehostname) deal with
authentication of the PPP line, preventing unwanted usage and access. We will look at
authentication later in this section. The lock keyword tells pppd to use UUCP-style file
locking to prevent device clashes. Locking should be used on all PPP systems to prevent
problems.
The pppd daemon echoes all warnings and error messages to the syslog facility. If you
used the -v option with the chat script, chat's messages are also sent to syslog. If you
are having trouble with your PPP connections, you can check the syslog for details and try
to isolate the problem.
Syslog discards incoming error and warning messages, unless an entry in the
/etc/syslog.conf file redirects them to another file. To save the messages from pppd and
chat, add this line to the /etc/syslog.conf file:
daemon.* /tmp/ppp-log
This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log
file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of
the syslog.conf file insist on tabs to separate the columns instead of spaces. Once your
script is working, remember to remove this line or the log file will grow quite large!
If you really want to watch what is going on with pppd, you can invoke a debugging
option with the kdebug command followed by a number. The three values for debugging are:
| 1 | general debug messages |
| 2 | display incoming HLDC data |
| 4 | display outgoing HLDC data |
The numbers are added together to give the debug level you want. For example, the
command kdebug 5 will display all general debug messages and all outgoing HLDC data. A
value of 7 displays everything (this display gets very long). You can send the output to a
file or the console.
PPP is a wonderful protocol for modem-based communications, but it has one major
problem: it has security holes large enough to drive a bus through. If incorrectly
configured even slightly, anyone can use the PPP line to get into your machine, or use the
PPP line to get out to other systems. To help prevent this, authentication is often used.
Authentication essentially makes sure that each end of the connection is who they say they
are and are allowed to use the link.
PPP uses two authentication schemes: the Password Authentication Protocol (PAP) and the
Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure.
When one machine sends the login name and password to the other, the receiving machine
verifies the information with a database on its end. While simple, PAP has the problem
that anyone can tap into the line and monitor the passwords being sent.
CHAP solves this problem, and hence is the most favored form of authentication for PPP
links. CHAP enables one machine to send a random string to the other, along with its
hostname. The other end uses the hostname to look up the proper reply, combine it with the
first string, encrypt it, and then resend it to the first machine along with its hostname.
The first machine performs the same sort of manipulation on the random string it first
sent, and if the two replies match, the authentication is complete. CHAP doesn't
authenticate only at start time, but at random intervals throughout the connection, which
adds to its power.
When two machines connect, they don't use authentication unless explicitly instructed
to do so (see the auth entry in the /etc/ppp/options file, discussed earlier). When
authentication is active, one end will try to use CHAP first, then, if that fails because
the other end doesn't support CHAP, it will use PAP. If neither authentication scheme is
supported by the other end, the connection is terminated. If you are going to use
authentication for all your PPP connections, put the auth entry in the /etc/ppp/options
file. If not all your connections support authentication, then those connections will fail
if auth is specified.
The information needed for both CHAP and PPP are kept in two files called
/etc/ppp/chap-secrets and /etc/ppp/ppp-secrets respectively. When authentication is
active, one end will check the other for these files, trying CHAP first. If you are going
to use authentication for all your connections (which is a very good idea), you can build
up the chap-secrets and pap-secrets files. If you configure both chap-secrets and
pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can
connect to your machine.
The /etc/ppp/chap-secrets file consists of four columns for the client name, the server
name, the secret password string, and an optional list of IP addresses. The behavior of
the system is different depending on whether the local machine is being challenged to
authenticate itself or is issuing a challenge to the remote. When the local machine has to
authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the
client field that matches the local host name and the server field equal to the remote
hostname, and then uses the string to build the authentication message. Such an entry in
the /etc/ppp/chap-secrets file looks like this:
# client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS"
This entry will use the string "I hate DOS" to build an authentication
message back to big_guy.big_net.com. The quotations are necessary to surround the string
in the file. (The addresses column is discussed below.) If you are setting up your system
to connect to three different PPP remotes, you will want an entry for each server, so your
file may look like this:
# client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"
When your machine is sending the challenge, the process is reversed. The pppd daemon
looks for the remote hostname in the client field, the local hostname in the server field,
and uses the string to compare the encryption results with the string sent back by the
remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this:
# client server string addresses big_guy.big_net.com merlin.tpci.com "Size isn't everything"
Again, you will have an entry for each remote machine you may need to authenticate. You
can see that you will end up having mirror image entries for the client and server fields
for each machine you connect to (as either end may require authentication at any time). A
simple /etc/ppp/chap-secrets file really looks like this:
# client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" big_guy.big_net.com merlin.tpci.com "Size isn't everything" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker" roy.sailing.ca merlin.tpci.com "Man overboard"
The size of the file could get quite large, so CHAP enables you to use a wildcard
match, usually only for your local machine. For example, in the /etc/ppp/chap-secrets file
below:
# client server string addresses merlin.tpci.com big_guy.big_net.com "I hate DOS" big_guy.big_net.com merlin.tpci.com "Size isn't everything" merlin.tpci.com chatton.cats.com "Meow, Meow, Meow" chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty" merlin.tpci.com roy.sailing.ca "Hoist the spinnaker" * merlin.tpci.com "Man overboard"
the last entry enables any other machine connecting to the localhost and requiring
authentication to use the same string. Of course, the remote must have the same string in
its chap-secrets file. This is a little less secure than a dedicated string for each
remote, but can be a handy time-saver when using a number of machines only rarely.
The addresses field, which wasn't used in the samples above, enables you to list either
symbolic names or IP addresses for the clients. This is necessary if the remote wants to
use an IP address other than its normal one, which would cause the authentication to fail
normally. If the address field is empty (as they all are in the samples), any IP address
is allowed. A hyphen in the field disallows all IP addresses with that client.
The /etc/ppp/pap-secrets file is much the same as the chap-secrets file. The fields in
the pap-secrets file are the client (called a user in the pap-secrets format) and server
names, a secret string, and valid address aliases. However, the look of the file is
different because the client and server names are not full domain names and the secret
string is a single block of text. A sample pap-secrets file looks like this:
# /etc/ppp/pap-secrets # user server string addresses merlin darkstar yG55Sj29 darkstar.big_net.com darkstar merlin 5Srg7S merlin.tpci.com merlin chatton MeowMeow chatton.cats.com chatton merlin 73wrh6s merlin.tpci.com
In this example, the first two lines show a connection to the machine darkstar. The
first line is how we authenticate a request from darkstar, and the second how we
authenticate a request from us to them. The user name in the first column is the name we
send to the remote, while the server field is their identification to us. This poses a
problem: the pppd daemon has no way of knowing the remote host's name, because all it gets
is an IP address. You can put the IP address in the addresses column of the file, or you
can specify the remote host name at the end of the pppd command line like this:
pppd ..... remotename chatton user merlin
This shows that the remote is called chatton, and our local host is merlin. The last
portion giving the local host name overrides the default values, if specified.
If you are using SLIP or PPP to connect to the Internet for more than simple tasks
(such as downloading e-mail and news), you will probably want to use DNS. The basic
configuration for DNS and BIND were discussed in Chapter 30,
"Configuring TCP/IP."
The easiest method of using DNS for your SLIP and PPP connections is to put the IP
address of a name server you can access in the /etc/resolv.conf file. For example, if you
can access a name server with an IP address of 45.2.12.1, you would make the following
addition to your /etc/resolv.conf file:
# /etc/resolv.conf domain merlin.com # the local domain nameserver 145.2.12.1 # the Internet name server
Once this entry has been established, SLIP or PPP will send requests for address
resolution to the name server and wait for replies. The more accessible the name server
is, the better the performance will be. For this reason, choose a name server that is
relatively close (in network terms).
Using this approach has a problem, though: all address resolution attempts must go out
over the SLIP or PPP line. This can slow down applications, as well as increase the amount
of network traffic over your SLIP or PPP line, sometimes to the detriment of other
applications. A way around this problem is to set up a cache-only name server on your
machine. As you may recall from Chapter 30, a name server uses a
cache to retain the most commonly used addresses. Since most SLIP and PPP connections are
to a few machines only, the cache can dramatically reduce the amount of resolution traffic
on the SLIP or PPP link.
To set up a cache-only name server, you need to modify the /etc/named.boot file. To set
your local machine up as a cache-only name server, your named.boot file would look like
this:
; /etc/named.boot directory /var/named cache db.cache ; cache-only primary 0.0.147.in-addr-arpa db.cache ; loopback
The file above uses the local network name in IN-ADDR-ARPA format to specify the
loopback driver, and the cache points to the file db.cache, which contains a list of root
name servers.
Once you have performed all the configuration steps and startup instructions mentioned above for SLIP and PPP, you can use the interfaces to the outside world. The applications that make use of SLIP and PPP usually expect only to be told where the interface is, and then to work without any interference from you. SLIP is much easier to configure than PPP, but PPP has faster throughput and more security features that make it attractive if you are using a modem connection a lot.
